chore(deps): update github actions - #151

v8.4.1

Compare Source

What's Changed

• Update dependency node to v26 by @​renovate[bot] in #​294
• SQSCANGHA-184 Bump undici from 6.28.1 to 6.29.1 by @​dependabot[bot] in #​289
• SQSCANGHA-191 Bump scanner-cli version to 8.3.1.16491 by @​jerome-chetelat-sonarsource in #​298

New Contributors

• @​jerome-chetelat-sonarsource made their first contribution in #​298

Full Changelog: SonarSource/sonarqube-scan-action@v8.4.0...v8.4.1

v1.0.269

Compare Source

Full Changelog: anthropics/claude-code-action@v1.0.268...v1.0.269

v1.0.268

Compare Source

Full Changelog: anthropics/claude-code-action@v1.0.267...v1.0.268

v1.0.267

Compare Source

Full Changelog: anthropics/claude-code-action@v1.0.266...v1.0.267

v4.39.3

Compare Source

• Fixed diff-informed alert filtering incorrectly removing alerts in changed files whose paths contain spaces, special characters, or non-ASCII characters. #​4283

v4.39.2

Compare Source

• Update default CodeQL bundle version to 2.27.4. #​4284
• Upcoming breaking change: CodeQL version 2.22.3 and earlier were discontinued on 16 October 2026 alongside GitHub Enterprise Server 3.18, and will be unsupported by the next minor release of the CodeQL Action. Added a deprecation warning for customers using these versions of CodeQL. #​4266
• Starting with macOS 27 and Xcode 27, traced analyses are unsupported. See this blog post for more information. The CodeQL Action will now try to identify if a workflow is about to perform a traced analysis on version 27 or above of macOS or Xcode. If so, the CodeQL Action will emit a corresponding warning that will also be visible on the Tool Status Page. This check will be rolled out following this release of the CodeQL Action. #​4221
• The undocumented TRAP cache cleanup feature that could be enabled using the CODEQL_ACTION_CLEANUP_TRAP_CACHES environment variable has been removed, as announced in the release notes for CodeQL Action 4.35.2. The analyze Action now warns if this environment variable is set. If you used TRAP cache cleanup to limit Actions cache usage, we recommend disabling TRAP caching by passing the trap-caching: false input to the init Action. #​4243

v5.2.7: : Retry failed mise downloads with backoff and show the HTTP status

Compare Source

When the action can't download mise, the log now shows the HTTP status and host for each failed attempt. Retries wait longer between attempts, so a short GitHub outage is less likely to fail the job.

Fixed

• Download failures now show what went wrong, and brief outages are retried for longer. Before this release, a failed mise download logged only The process '/usr/bin/curl' failed with exit code 22 and retried five times with a fixed 2-second wait. From that message you couldn't tell a rate limit from a missing asset or a server error. Each failed attempt now logs the HTTP status and the host that answered:

  Download attempt 1/6 failed: Could not download github.com/…/mise-v2026.10.21-linux-x64.tar.zst (HTTP 503 from github.com). Retrying in 3.4 seconds.
  

  The wait between attempts doubles from about 2s up to a 30s cap, with random jitter, so the five retries cover roughly a minute. Only transient failures are retried: connection errors and timeouts, and HTTP 408, 429 and 5xx responses. A 404, any other 4xx, or a local file-write error fails at once. The log shows only the host and file name of each URL, never signed query strings or curl/wget stderr. Partial files are deleted before the next attempt. wget now runs with --tries=1, so its own 20-retry default no longer stacks on top of the action's retries. This applies to every download the action makes: the release archive, checksums and the packslip bundle. Checksum and signature verification are unchanged, and there are no new inputs. (#​722 by @​jdx, fixes #​721)

Changed

• packslip, which the action uses to verify downloaded mise releases, is updated from 1.11.0 to 1.11.2. This version includes upstream hardening of its verifier checks. (#​726)

Full Changelog: jdx/mise-action@v5.2.6...v5.2.7

v5.2.6: : Fix step hanging after a failed cache restore

Compare Source

The action now exits as soon as its work is done. Before this release, a cache restore that failed during the download could leave the step running for up to ten minutes after setup had finished.

Fixed

• A failed cache restore no longer leaves the step hanging. If the mise cache download failed partway through, for example with getaddrinfo EAI_AGAIN, the action logged a warning, installed the tools and saved the cache, then stopped producing output. The step stayed in progress until the job was cancelled or a timer inside @actions/cache fired after 10 minutes. That timer is left running when a download fails (actions/toolkit#2470), and it kept the Node process alive. The action now exits explicitly after both the main step and the post step finish. It waits up to 5 seconds for log output to flush, then exits. The exit code set by any earlier failure is kept. Errors that aren't Error objects now mark the step as failed with their message. Before, they caused an unhandled rejection. (#​718 by @​jdx and @​kjanat, fixes #​717)

Full Changelog: jdx/mise-action@v5.2.5...v5.2.6